Date: Wed, 08 Jan 1997 21:51:41 GMT
Server: NCSA/1.4.2
Content-type: text/html

<HTML>
<head>
<title>CSE 403 General Info</title>
</head>
<body>
<h1>CSE 403: Software Engineering - General Info</h1>
<h3>David Notkin, Winter 1995 </h3>


<MENU>
<li><b>Where & When</b>
<MENU>
<li>323 Sieg, MWF 10:30--11:20
</MENU>

<li><b>Instructor</b>
<MENU>
<li>David Notkin
<li>414 Sieg Hall
<li>685-3798
<li>notkin@cs.washington.edu
</MENU>

<li><b>Teaching Assistant</b>
<MENU>
<li> <!WA0><!WA0><a href="http://www.cs.washington.edu/homes/kingsum/">Kingsum Chow</a> 
<li>kingsum@cs.washington.edu
</MENU>

<li><b>Office Hours</b>
<MENU>
<li>Check the <!WA1><!WA1><a href="http://www.cs.washington.edu/education/courses/403/95w/sched.html">online schedule</a> 
        for definitive information about office hours for the instructor
	and the TA.  
</MENU>

<li><b>Required Work</b>
	<MENU>
	<li> Participation in designing, building, and presenting a
	  team project.
	<li> A midterm examination.
	<li> A final examination.
	</MENU>

<li><b>Readings</b>
<MENU>
<li> Brooks,<cite>The Mythical Man-Month [MMM]</cite>.
<li> Ghezzi, Jazayeri, and Mandrioli [GJM],
        <cite>Fundamentals of Software Engineering</cite>.
	(You may use other similar books: see Notkin for details.)
<li><b>There's also a lot in this and other handouts; I expect you
	to read them carefully.</b>
</MENU>

<li><b>Exams</b>
<menu>
<li>The examinations are tentatively scheduled to be given on Monday
	February 6 (in class) and at the regularly scheduled final (Monday
	March 13, 9:30-10:20AM).  The midterm examination will cover material
	up to and including design.  The second examination will be
	comprehensive.
</menu>

<li><b>Grading</b>
<MENU>
<li> Your contribution to the project will account for about 75% of your
total grade.  The midterm will account for about 10% of your grade,
and the final will account for another 15%.  Intangibles, such as
class participation, may affect your grade as well.  Your project
grade will be based on the quality of your work, not just on your
effort.  You, not the project, will be graded; individuals in a group
generally receive different grades.

<li>Final evaluation of the group projects is done by (1) a demonstration
of the project, (2) a group discussion of the project and the process
of building it, and (3) separate discussions with each individual
group member.  This is a time-consuming process that will take place
on Tuesday March 14 and Wednesday March 15.  Plan accordingly. 
</menu>

<li><b>Lectures</b>
<MENU>
<li>Most of the lectures will cover topics such as the software lifecycle,
characteristics of large systems, software specification, software
design techniques, development tools, testing, verification, and
validation, maintenance, etc.  As much as possible, lectures will be
coordinated with associated stages of the project.  There may be two
or three invited lecturers, giving their impression of software
engineering, and of the problems with software engineering, at various
companies.

<li>
The following chart shows the tentative schedule for lectures, exams,
etc.  It is subject to frequent change.
<pre>

	Week	Monday		Wednesday	Friday
	1/2 	No class	Overview	Overview/Lifecycle
	1/9	Lifecycle	Requirements	Requirements
	1/16 	No class	Design		Design
	1/23    Design		Design		Design
	1/30	Testing		Testing		Testing
	2/6	Midterm		Formal Methods	Formal Methods
	2/13	Inspections	Environments	Environments
	2/20	No class	Safety		Reliability
	2/27	Architecture	Process		Metrics
	3/6	TBA		TBA		TBA
</pre>

</menu>

<li><b>Sections</b>
<menu>
<li>Sections will be used in a variety of ways, including group meetings
(both among yourselves and also with the TA and/or me), presentations
by groups to other groups, etc.
</menu>

<li><b>Project Requirements</b>
<menu>
<li>Large-scale software projects require teams of designers,
implementors, and support staff.  Because of this, the construction of
these projects demands not only technical abilities but also skills in
group dynamics.  To give you some experience with these dynamics, you
will form groups of four to six people to specify the requirements of,
design, and implement the assigned project (described below).

<li>You must produce your system according to the schedule that will be
handed out on Friday.  The schedule includes several milestones, each
represented by a specific artifact.  (As a preview, the draft of the
requirements specification document, the first milestone, will be due
on Wednesday 18 January.)  It is not necessary that every group member
be involved in meeting each milestone.  For instance, a person in
charge of testing the complex system may not need to understand the
low-level implementation choices.  However, you are required to state
explicitly who has been involved in each milestone and in what
capacity.  I recommend strongly that each document be written by a
single person, with editing help from the others.

<li>I will provide additional information, on a timely basis, about what I
expect from each artifact; the document describing requirements
specifications will be handed out on Wednesday.  (I do not have a full
set of high-quality artifacts for a similar project.  This would be
nice, but it is surprisingly difficult to acquire.)  Sticking to the
schedule for each artifact is essential, so that you can complete the
entire project during the quarter.  If for some reason the schedule
does not meet the needs of your group, I will consider alternatives if
careful, reasoned motivations are given.  Don't plan on working on
just one milestone at a time; you must always have (at least) part of
your team looking ahead towards milestones that are coming up.

<li>The project description is intentionally under-defined.  As a group,
you will be responsible for making decisions about the user interface,
the data structures, and so forth.  One goal of the milestones is to
help your group make these decisions in an orderly manner.  Feel free
to ask questions about what is expected.  The TA and I will try to
answer these questions as if we were your customers (although with
some special knowledge about the constraints of a one- quarter
course).

<li>Some other details include:

<menu>
<li>Every team must select a name.

<li>Every team must take and keep minutes at all of your meetings.
The motivation for the minutes is that you may otherwise forget
decisions that you made, which is costly in terms of time and energy.
Do not spend time formatting these; handwritten minutes are just fine.
They should be copied and distributed to all appropriate group
members.  Bring an extra copy of these minutes every Tuesday during
section; we'll scan these to see how your team is progressing and will
keep them for our records.

<li>Every individual must keep a personal log.  The logs will be
checked on occasion at sections.  They are intended to help both you
and us keep track of where your time is going.  The log, which is not
very different from time sheets that many employers require you to
complete, includes the date, the description of the activity, the time
it took, and some explanatory text.  The following is a sample; you
may select different categories, but be consistent.  As with the
minutes, don't format these.  You may find that keeping them in a
bound notebook is effective.  Bring these to Tuesday sections; we'll
also want to have them turned in at the end of the quarter.  Here is
an example of a few entries from a personal log.

<pre>

	Date	Category		Time (Hours)	Notes
	30 Sep	Lecture			1.0		Notkin's intro
	1 Oct	Project Planning			Jane & Biff join group
	2 Oct	Lecture			1.0		Intro continued
							Didn't follow a word
	2 Oct	Reading			3.0		MMM Chaps 1-7
							(Better than he said!)
	2 Oct	To Do in Future				Read "No Silver Bullet"
	3 Oct	Lecture			1.0		Basic SW life cycle
	3 Oct	Reading			2.0		Finished MMM
</pre>

Note that some of the entries are essentially instantaneous (forming
your group may or may note be like this) and need not have times
attached.  Others are prescriptions for later things to do (either
during or even after the course).  You may have categories later in
the course for group meetings, planning, editing, debugging, etc.

<li>The development language you will use is either Ada or C++.  In some
cases, given a good motivation, I might grant permission for a group
to use an alternative language.  But in no case will I permit a group
to use a language for which all group members who will be programming
do not have expertise; there is too much to do this quarter to add on
the burden of learning another programming language.

<li>Your group must communicate well.  In addition to selecting a
management structure, I recommend that you decide on firm times for
group and subgroup meetings.  You may wish to distinguish among status
updates, brainstorming meetings, decision-making meetings, etc.

<li>Your group may lose a member for various reasons.  If this happens,
you will be expected to close ranks and adjust to the problem.  Losing
personnel does happen in the real world and is another motivation for
carefully documenting each step along the project path.

<li>Because software development is less predictable than is desirable,
you should plan from the beginning for reasonable subsets of the
system.

<li>Computer resources always seem to be the most precious when they are
needed the most.  The real world is no different from academia in this
respect: machines are often loaded or unavailable at critical times.
You have been warned.

<li>People in projects make mistakes.  They don't save their files
before a crash, or they inadvertently delete key directories.  Be
careful and try to develop managerial or technical approaches for
reducing this kind of error.  Similarly, you need approaches for
helping your group keep track of multiple versions of artifacts,
including code.

<li>This course is time-consuming, so make sure to use your time well.
Don't stare off into space while a program is compiling.  Don't draw
complex figures using a computer if a quick sketch by hand is
sufficient.  Don't debug by just permuting the statements in your
program.
</menu>
</menu>

<li><b>Project Description</b>
<menu>
<li>Check the <!WA2><!WA2><a href="http://www.cs.washington.edu/education/courses/403/95w/project.html">Project Description</a> for
information about this quarter's project.
<li>Check the <!WA3><!WA3><a href="http://www.cs.washington.edu/education/courses/403/95w/project-sched.html">Project Schedule</a> for
information about the project schedule.
</menu>
</menu>

<pre>


</pre>
<hr>
<address>
notkin@cs.washington.edu           (Last Update: 1/6/95)
</address>
</body>
</html>
        
